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Verifying  Safety  Properties  Using 
Non-deterministic  Infinite-state  Automata* 


Nils  Klarlundt  Fred  B.  Schneider 
September  8,  1989 


Abstract 

A  new  class  of  infinite-state  automata,  called  safety  automata,  is 
introduced.  Any  safety  property  can  be  specified  by  using  such  an 
automaton.  Sound  and  complete  proof  obligations  for  establishing 
that  an  implementation  satisfies  the  property  specified  by  a  safety 
automaton  are  given. 


1  Introduction 

A  central  problem  in  program  verification  is  establishing  that  an  imple¬ 
mentation  satisfies  some  specification  of  interest.  Various  ways  to  solve 
this  problem  have  been  explored  [7].  One  recent  and  promising  direction  is 
to  extract  proof  obligations  for  an  implementation  directly  from  an  automa¬ 
ton  formulation  of  that  specification.  This  approach  was  first  introduced 
in  [3]  for  a  limited  class  of  specifications  and  was  subsequently  extended 
in  [5]  and  [14]  to  handle  any  specification  that  could  be  expressed  using 
finite-state  (Buchi)  automata. 

•This  material  is  based  on  work  supported  iu  part  by  the  Office  of  Naval  Research  un¬ 
der  contract  N00014-86-K-0092,  the  National  Science  Foundation  under  Grant  No.  CCR- 
8701103,  and  Digital  Equipment  Corporation.  Any  opinions,  findings,  and  conclusions  or 
recommendations  expressed  in  this  publication  are  those  of  the  authors  and  do  not  reflect 
the  views  of  these  agencies. 

^Supported  by  a  grant  from  the  University  of  Aarhus,  Denmark. 
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However,  the  class  of  specifications  that  can  be  expressed  using  Biichi- 
automata  does  not  include  all  properties  of  interest.  There  exist  important 
properties  that  only  can  be  expressed  using  infinite-state  automata.  Proper¬ 
ties  described  by  first-order  temporal  formulas  with  universal  quantification 
over  global  symbols  [13]  are  examples  of  such  properties.  These  properties 
include  real-time  response  as  well  as  specifications  involving  unbounded 
buffers.  The  methods  in  [5]  and  [14]  also  suffer  from  another  limitation: 
they  do  not  directly  deal  with  properties  expressed  using  non-deterministic 
automata.  Yet,  in  some  cases,  using  non-determinism  allows  more  natural 
and  more  concise  specifications  because  different  assumptions  about  future 
courses  of  events  can  be  considered  independently.  In  contrast,  determin¬ 
ism  requires  all  such  assumptions  to  be  considered  at  the  same  time  and 
can  lead  to  a  state-explosion  in  the  automaton. 

This  paper  extends  automaton-based  approaches  for  verification  to  in¬ 
clude  properties  expressible  by  a  class  of  non-deterministic  infinite-state 
automata,  called  safety  automata,  that  are  powerful  enough  to  specify  any 
safety  property.  Safety  properties  assert  that  some  “bad  thing”  does  not 
happen  during  execution  of  an  implementation.  Examples  of  safety  prop¬ 
erties  include  deadlock-freedom,  where  the  bad  thing  is  occurrence  of  dead¬ 
lock;  mutual  exclusion,  where  the  bad  thing  is  simultaneous  access  of  several 
processes  to  a  shared  resource;  and  real-time  response  properties  such  as 
“a  reply  is  received  within  5  seconds”,  where  the  bad  thing  is  that  no  reply 
is  received  by  the  6th  second. 

Safety  automata  cannot  specify  liveness  properties,  properties  asserting 
that  some  “good  thing”  does  happen  during  execution.  The  automata 
used  in  [5]  and  [14]  could  express  certain  liveness  properties.  Thus,  at 
the  expense  of  not  handling  liveness  properties,  the  approach  described  in 
this  paper  extends  automaton-based  verification  to  the  class  of  all  safety 
properties. 

The  main  contribution  of  this  paper  is  to  give  sound  and  complete  proof 
obligations  for  deducing  that  a  given  implementation  satisfies  the  property 
specified  by  a  safety  automaton.  These  obligations  are  presented  in  two 
forma.  First,  they  are  given  in  terms  of  an  invariant  relating  states  of  the 
implementation  and  of  the  automaton.  Second,  the  obligations  are  given 
in  a  style  similar  to  that  of  Hoare’s  programming  logic  [9]. 

The  organization  of  this  paper  is  as  follows.  In  section  2,  we  intro¬ 
duce  a  notation  for  describing  infinite-state,  non-deterministic  automata. 
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Section  3  defines  safety  automata  and  proves  that  the  properties  they  can 
specify  is  exactly  the  class  of  safety  properties.  Automata  to  model  imple¬ 
mentations  are  described  in  section  4.  Next,  in  section  5,  we  give  sound  and 
complete  proof  obligations  to  verify  that  an  implementation  satisfies  a  prop¬ 
erty  specified  by  a  safety  automaton.  In  section  6,  these  proof  obligations 
are  reformulated  as  Hoare  triples;  and,  sound  and  complete  decomposition 
principles  that  allow  triples  to  be  broken  into  simpler  ones  are  given.  The 
method  is  illustrated  in  section  7  with  an  example.  Finally,  relation  to 
other  work  and  conclusions  appear  in  section  8  and  section  9. 

2  Properties  and  Automata 

Formally,  a  property  defines  a  set  of  infinite  sequences  of  events.  Events 
may  be  states  of  an  implementation  or  actions  of  an  implementation — our 
results  are  independent  of  the  view  taken,  hence  the  neutral  term  “event” . 
An  implementation  II  is  regarded  as  a  generator  of  events,  and  the  property 
L(U)  defined  by  II  is  the  set  of  sequences  of  events  generated  by  executing 
II.  A  specification  E  also  defines  a  property.  This  property,  T(E),  consists 
of  all  event  sequences  that  satisfy  the  specification.  An  implementation  II 
satisfies  a  specification  E  if  and  only  if  L(H)  C  L( E),  that  is  every  event 
sequence  generated  by  II  satisfies  E. 

2.1  Automata  Diagrams 

An  automaton  defines  the  property  consisting  of  exactly  those  sequences  of 
events  that  it  accepts.  As  an  exam  3,  for  a  system  whose  interface  consists 
of  a  register1  N  and  a  green  light,  a  *er  the  property2  V  containing  all 
sequences  in  which  the  first  event  is  loading  N  with  some  value  n  such 
that  subsequently  the  green  light  is  flashed  at  most  n  times.  If  events 
model  actions,  then  V  concerns  two  types  of  actions,  “loading  register  N” 
and  “flashing  the  green  light”,  although  an  implementation  might  perform 
other  actions  as  well.  If  events  model  states,  then  V  concerns  states,  where 
a  state,  among  other  things,  assigns  a  value  to  N  and  indicates  whether  the 
green  light  is  illuminated. 

typewriter  font  is  used  for  variables  in  programs  or  specifications. 

3Caligraphic  letters  V,  Q,  ft  and  5  are  used  for  properties. 
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Figure  1:  Aj>,  an  example  automaton  diagram. 

We  employ  automaton  diagrams  to  define  the  infinite-state  automata 
we  use  to  specify  properties.  Figure  1  is  an  example  of  an  automaton 
diagram.  It  represents  an  automaton  A-p  for  property  P,  assuming  events 
are  actions.  An  automaton  diagram  is  a  directed  graph,  not  unlike  the 
usual  representation  of  a  finite  state  automaton  [10].  However,  in  order  to 
describe  an  infinite  state  space,  the  diagram  includes  node  variables.  This 
permits  a  single  node  to  denote  a  set  of  automaton  states.  For  example, 
the  diagram  of  Figure  1  has  two  nodes3  A  and  B,  where  node  B  introduces 
a  node  variable  C  by  naming  it  under  a  dashed  line.  Node  variable  C  is  used 
as  a  counter  that  bounds  the  maximum  number  of  times  the  green  light 
may  still  flash  in  a  given  execution. 

Each  node  in  an  automaton  diagram  contributes  a  set  of  automaton 
states.  In  Figure  1,  automaton  states  defined  by  node  B  have  the  form 
(B,(C)),  where  C  is  an  integer.  Node  A  defines  a  single  state,  (A,  ()), 
abbreviated  (A).  Thus,  the  set  of  automaton  states  for  Ap  is  {(A)}  |J 
{(B,  ( C ))  |  integer(C)}.  In  general,  a  node  P  that  introduces  node  variables 
Xi,...,X*  defines  automaton  states  of  the  form  (P,  (Xi, . . .  ,Xn)),  where 
(Xi, . . . , A’n),  also  denoted  jt,  is  a  value  assignment  that  associates  the 
value  Xi  with  node  variable  X,.  We  say  that  an  automaton  is  in  a  node  P 
if  the  automaton  is  in  a  state  of  the  form  (P,  (. . .)). 

3Boldface  capital  letters  are  used  to  designate  nodes  of  a  automaton  diagram. 
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Edges  in  an  automaton  diagram  are  labeled  by  transition  predicates  *  A 
transition  predicate  labeling  an  edge  between  a  node  'P  and  a  node  P'  may 
mention  node  variables  of  'P,  node  variables  of  P',  and  event  functions. 
An  event  function  f  (e)  maps  an  event  e  to  a  value.  The  value  of  an  event 
function  f  ()  appearing  in  a  transition  predicate  is  f  (e),  where  e  is  the  event 
on  which  the  transition  is  taken. 

In  a  transition  predicate,  we  write  'X  to  denote  a  node  variable  X  that  is 
introduced  by  'P  and  write  Y'  to  denote  a  node  variable  Y  introduced  by  P'. 
Transition  predicates  define  automaton  transitions  in  the  expected  way:  an 
event  e  may  cause  a  transition  from  a  state  ('P,'X)  to  a  state  (P',  X')  if 
there  is  an  edge  from  node  'P  to  node  P'  in  the  automaton  diagram  and 
this  edge  is  labeled  by  a  transition  predicate  satisfied  by  'X  and  X’  and  e. 
For  example,  consider  the  self-loop  in  Figure  1  labeled 

greenj.ight()  =  flash  A 'C  >1  AC'  =  'C  —  1. 

It  asserts  that  if  an  event  occurs  for  which  the  event  function  green_light  () 
has  value  “flash”  and  the  automaton  is  in  a  state  (B ,'C)  with  'C  >  1, 
then  a  transition  is  possible  to  state  (B ,C")  where  C‘  =  'C  —  1  holds. 
By  convention,  an  explicit  predicate  need  to  be  not  given  for  a  variable 
that  does  not  change  its  value  during  a  transition.  Thus  in  Figure  1,  the 
predicate  'C  =  C'  is  assumed  for  the  transition  corresponding  to  the  self-loop 
labeled  green_light()  =  off. 

For  automaton  states  'q  and  q’,  we  write  q  A  q'  if  the  automaton  may 
enter  state  q  from  state  %q  when  event  e  occurs.  The  relation  — ♦  is  called 
the  transition  relation  for  the  automaton.  When  'q  A  q’  holds,  q'  is  said  to 
be  a  successor  state  of  'q  on  e. 

For  example,  the  transitions  of  A-p  from  node  B  to  node  B  are 
(B,'C)  A(B,C0 

if  mad  only  if 

(gr*«n-light(e)  =  flash  A  C'  =  'C  —  1  A  'C  >  1) 

V  (green_light(e)  =  off  A  C'  =  'C). 

4  Although  here  we  define  automata  by  means  of  predicate  logic,  our  verification  method 
is  not  dependent  on  any  assumptions  about  recursiveness  of  transitions  and  state  spaces. 
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An  initial  node  P  of  an  automaton  diagram  is  a  node  that  has  an  in¬ 
coming  edge  with  no  origin  node.  Such  an  edge  may  be  labeled  with  a 
predicate  restricting  values  of  the  initial  states  that  correspond  to  node  P. 
The  set  of  all  initial  states  is  the  set  of  states  of  initial  nodes.  In  Figure  1, 
there  is  only  one  edge  without  an  origin  node.  This  edge  terminates  at  A, 
so  the  set  of  initial  states  for  A?  is  {(A)}. 

In  general,  an  infinite-state  automaton  A  is  defined  by  a  four-tuple 
(£,  Q,  Q°,  -*)  where 

•  £  is  the  (finite  or  countable)  set  of  events, 

•  Q  is  the  (finite  or  countable)  set  of  automaton  states, 

•  Q°  C  Q  is  the  set  of  initial  states,  and 

•  — »  is  the  transition  relation. 

An  automaton  A  defines  a  property  L(A),  consisting  of  all  words  ac¬ 
cepted  or  generated  by  the  automaton.  An  infinite  event  sequence,  w  = 
eo,  ei, . . .  in  £w  is  accepted  by  A  if  and  only  if  there  is  a  run  of  A  over  w, 
where  a  run  of  A  over  w  is  a  sequence  of  automaton  states  g0,  gi, . . .  such 
that  qo  is  an  initial  state  (i.e.  g0  €  Q°),  and  go  ^  9i  A  g? . . .  holds.5  An 
automaton  is  deterministic  if  it  has  only  one  inititial  state  and  if  for  all 
states  g  and  all  events  e  there  is  at  most  one  state  q  such  that  g  A  g'.  A? 
of  Figure  1  is  a  deterministic  automaton. 

Finally,  we  give  some  notation  that  will  be  required  later.  Consider  the 
automaton  A  =  (£ ,  Q ,  Q°,  —*).  For  u  =  eo, . . . ,  e„  G  £*  and  g,  q  €  Q,  we 
write  g  A  q  instead  of 

3go>  •  •  •  >  gn+i  €  Q  •  qo  A  •  •  •  A  qn+l  a  go  =  g  a  g„+i  =  g . 

Note  that  if  u  is  the  empty  string,  then  g  A  g'  if  and  only  if  g  =  q.  We  say 
that  automaton  state  g  is  reachable  by  u  if  go  A  q  for  some  go  €  Q°-  State 
g  is  rtmchahle  if  it  is  reachable  by  u  for  some  u  €  S*. 

*£*  is  the  set  of  all  infinite  words  over  £. 
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3  Safety  automata 

The  informal  characterization  of  safety — that  no  “bad  thing”  happens — can 
be  formalized  as  follows  [2].  A  property  S  is  a  safety  property  if  and  only  if 
every  infinite  sequence  of  events  w  £  S  has  some  finite  prefix  u  such  that 
no  infinite  extension  v  €  £w  exists  that  makes  u  •  v  G  S  hold.6  Here,  prefix 
u  defines  the  “bad  thing”.  In  terms  of  topology,  a  safety  property  defines 
a  closed  set  of  words  under  the  natural  topology  on  £w.  This  topology  is 
induced  by  defining  a  basic  open  set  to  have  the  form  u  •  £"  for  u  €  £*.7  An 
open  set,  the  countable  union  of  basic  open  sets,  can  be  written  u,  •  £", 
where  each  u,  is  in  £*.  Thus,  an  open  set  is  a  set  of  words  that  have  common 
prefixes  from  a  set  of  finite  words.  A  safety  property  S,  being  a  closed  set 
and  therefore  the  complement  of  an  open  set,  has  the  form  (J,  Uj  •  £".  Here, 
the  u,’s  represent  the  “bad  things”  proscribed  by  the  safety  property. 

As  shown  below,  safety  properties  are  exactly  the  properties  specifiable 
by  a  class  of  infinite-state  automata  that  we  call  safety  automata.  Safety 
automata  are  infinite-state  automata  that  have  a  finite  set  of  initial  states 
and  a  finitely  branching  transition  relation  (i.e.  for  all  states  's  and  all 
events  e,  the  set  of  successor  states  on  e,  {a'| 's  A  3'},  is  finite).  All 
deterministic  automata  are  safety  automata,  and  all  finite-state  automata 
are  safety  automata.  For  example,  A?  from  section  2  is  a  safety  automaton 
because  it  is  a  deterministic  automaton. 

The  following  two  propositions  generalize  results  in  [4]  from  finite  to 
infinite-state  automata. 

Proposition  1  Safety  properties  are  exactly  those  definable  by  deterministic 
infinite-state  automata. 

Proof  First,  we  prove  that  the  property  defined  by  a  deterministic  infinite- 
state  automaton  is  a  safety  property.  For  an  automaton  A  =  (£,  Q,  Q°,  — ►), 
define  a  partial  run  over  a  finite  word  eo, .  •  • ,  en  to  be  a  sequence  of  states 
qo,...  ,q*+ 1  such  that  q0  €  Q°  and  </0  A  •  •  •  A  gn+i.  Let  As  be  a  determinis¬ 
tic  infinite-state  automaton,  and  let  the  set  {u<  |  *  >  0}  be  the  set  of  strings 
u,  in  £*  such  that  there  is  no  partial  run  of  As  along  Uj.  Let  S  =  U<  «•  •  £", 
so  by  construction,  5  is  a  safety  property.  We  now  show  that  L(As)  =  S. 

6u  •  t>  is  the  sequence  obtained  by  concatenating  u  with  t>. 

7For  V  a  set  of  sequences,  define  u  •  V  to  be  {u  •  e|r  €  V). 
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L(As)  C5:  If  w  is  accepted  by  As,  then  from  the  definition  of  {uj|i  > 
0},  to  can  contain  no  prefix  from  among  the  tij’s.  Therefore,  w  €  S. 

S  C  L(As) ■  Let  to  be  in  S.  There  are  partied  runs  of  As  along  all  prefixes 
of  w.  (Otherwise,  by  definition  of  S,  to  would  not  be  in  5.)  Because  the 
automaton  is  deterministic,  these  partial  runs  are  ordered  under  the  prefix 
ordering  (either  any  two  runs  axe  equal  or  one  is  a  prefix  of  the  other). 
Their  limit  defines  a  run  over  to.  Hence,  tv  is  accepted  by  As- 

Next,  we  prove  that  every  safety  property  can  be  specified  by  a  deter¬ 
ministic  automaton.  Consider  a  safety  property  S  =  u,-  •  where  the 

Uj’s  are  in  £*.  To  construct  an  automaton  As  such  that  L(As)  =  S,  we 
proceed  as  follows.  Let  As  =  (£>{«»!*  >  0},{e},— ►$),  where  u  v  if 
and  only  if  u  •  e  =  v.*  This  defines  a  deterministic  automaton  that  checks 
that  its  current  state — the  past  sequence  of  events — does  not  contain  a 
prefix  among  the  Uj’s.  Thus,  to  €  L(As)  if  and  only  if  to  does  not  have  a 
prefix  that  is  in  {ujj*  >  0}  and  therefore,  to  6  L(As)  if  and  only  if  to  6  S.  □ 

Properties  defined  by  non-deterministic,  infinite-state  automata  need 
not  be  safety  properties.  To  see  this,  consider  &  property  asserting  that 
a  green  light  will  flash  eventually.  This  property  is  not  &  safety  property 
because  any  prefix  is  remediable:  simply  extend  the  prefix  with  an  event  in 
which  the  green  light  flashes.  A  non-deterministic  automaton  can  recognize 
this  property — the  automaton  starts  by  guessing  when  the  green  light  will 
flash  and  counts  down  to  that  event,  checking  that  the  green  light  has 
flashed  before  the  counter  reaches  0.  Because  the  set  of  initial  states  for  this 
automata  is  infinite,  the  automaton  is  not  a  safety  automaton.  In  fact,  the 
restrictions  in  the  definition  of  safety  automata  limit  their  expressiveness 
to  that  of  deterministic  infinite-state  automata: 

Proposition  2  All  safety  automata  express  safety  properties. 

Proof  A  construction,  similar  to  the  classic  subset  construction  for  finite- 
state  automata  [10],  can  be  applied  to  construct  a  deterministic  automa¬ 
ton  A4  from  a  finitely  branching  automaton  A  =  (£,Q,Q°,—>)  such  that 
L(A)  »  L{As)-  Let  the  deterministic  automaton  A4  be  (5,  F(Q),  {Q0},  —►<*), 
where  F(Q)  denotes  the  set  of  finite  subsets  of  Q  and  M  A  N  if  and  only 

8<  denotes  the  empty  string. 
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if  N  =  {.s*| 3  3  6  M  s.t.  a  a'}  ^  0.  The  result  now  follows  from  Proposi¬ 
tion  1.  □ 


Virtues  of  Non-Determinism 

Although  non-detenninistic  safety  automata  are  no  more  expressive  than 
deterministic  ones,  non-determinism  allows  some  safety  properties  to  be 
specified  more  naturally.  This  is  because  non- determinism  is  often  used 
implicitly  when  we  reason  about  the  future.  For  example,  the  property 

n  -.  (a)  p  is  true  and  then  q  will  always  be  true,  or 
(b)  r  is  true  and  then  3  will  always  be  true 

is  expressed  in  a  way  that  views  the  future  as  a  disjunction  of  two  different 
courses  of  events,  namely  (a)  and  (b).  Here,  p,  q ,  r  and  s  are  (not  necessarily 
disjoint)  predicates  about  events,  and  each  course  of  events  contains  expec¬ 
tations  about  the  future  that  are  not  implied  by  the  present.  For  example, 
up  is  true  and  then  q  will  always  be  true”  is  &  course  of  events  containing 
the  implicit  assumption  that  q  will  be  true  for  the  future,  although  this  is 
not  necessarily  the  case  just  because  p  is  true  of  the  present.  Having  p  true 
of  the  present  does  not  necessarily  ensure  this  course  of  events. 

Property  1Z  is  specified  both  using  a  non-deterministic  automaton  An 
and  a  deterministic  automaton  An4  in  Figure  2.  Observe  that  for  Ax* 
each  of  the  two  initial  nodes  corresponds  to  a  different  course  of  events — P 
corresponds  to  course  (a)  and  Q  corresponds  to  course  (b). 

Intuitively,  a  deterministic  automaton  like  An4  will  be  more  complicated 
than  its  non-deterministic  counterpart  because  each  state  in  An4  must  in¬ 
corporate  information  about  possible  courses  of  events.  Each  state  of  a 
non-deterministic  automaton  (like  An)  need  not  take  into  account  many 
possible  courses  because  the  state  itself  represents  an  assumption  about 
the  coone.  For  example,  if  both  p  and  r  are  true  for  the  first  event,  A^ 
male m  a  transition  from  PR  to  QS  because  both  a  continuation  of  course 
(a)  and  of  course  (b)  are  possible.  In  contrast,  An  can  w guess”  P  or  R, 
depending  on  the  course  that  will  transpire. 
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4  Implementation  automata 

Just  as  we  can  use  safety  automata  to  describe  specifications,  we  use  im¬ 
plementation  automata  to  describe  implementations.  An  implementation 
automaton  is  am  infurte-state  automaton.  Since  dead  states  can  be  deleted 
from  an  infinite-state  automaton  without  altering  the  language  accepted  by 
that  automaton  [8],  we  assume  that  implementation  automata  have  no  dead 
states.9  An  implementation  automaton  is  a  safety  automaton  if  its  set  of 
initial  states  is  finite  and  its  transition  relation  is  finitely  branching.  In  the 
abseil  e  of  unbounded  non-determinism,  all  programs  can  be  represented  as 
safety  automata.  The  verification  method  presented  in  this  paper,  however, 
works  even  for  implementation  automata  that  are  not  safety  automata. 

An  implementation  automaton  An  =  (£,  Qn,  t?n>  ~*n)  for  a  program  II 
is  defined  as  follows.  The  event  set  £  is  the  set  of  program  states;  the  set  Qn 
of  automaton  states  is  also  the  set  of  program  states;  the  set  of  initial 
automaton  states  is  the  set  of  initial  program  states;  and  the  transition 
relation  is  defined  such  that  'p  ^+n  P  if  and  only  if  some  atomic  action  of 
the  program  transforms  the  program  state  from  p  to  p\ 

Figure  3  is  an  example  of  program  Uu  that  runs  forever.  The  program 
state  is  defined  by  a  program  counter  and  two  variables,  a  and  b.  Thus, 
a  program  state  is  a  pair  p  =  (f,x),  where  l  denotes  the  value  of  the 
program  counter,  and  x  =  (a,b)  is  a  value  assignment.  To  formulate  the 
implementation  automaton 


4n„  =  (£,Qnu>Qne,'  ~*n «) 

for  this  program,  let  the  domain  of  program  labels  be  denoted  C  and  the 
domain  of  value  assignments  be  denoted  V.  Thus,  every  program  state  p 
is  an  element  o{  C  xV.  Define  £  and  state  space  Qn«*  to  be  C  x  V;  define 
Qn„  =  {(4)iz)|x  €  V};  and  define  transition  relation  — so  that,  for 

example,  it  includes  (f3,  (15, 30»  (M£r,)  (f3,  (16, 30)). 

9 A  4t*4  state  in  an  automaton  is  a  reachable  state  from  which  it  is  not  possible  to 
extend  any  partial  run. 


11 


4 :  (a,  b  0,  0) 

4  :  do  true  — ► 

4  :  (a  :»  a+1) 

4 :  (b  b+2) 

od 


Figure  3:  Program  He,. 


5  Proof  Obligations 

We  now  turn  to  the  question  of  establishing  that  an  implementation  satis¬ 
fies  a  specification.  In  particular,  we  develop  proof  obligations  for  demon¬ 
strating  that  L(An)  C  L(Az),  where  An  =  (£,Qn,Qn»-»n)  is  an  imple¬ 
mentation  automaton  and  As  =  (£,Qs,Qs,  — *e),  called  the  specification 
automaton,  is  a  safety  automaton.  Satisfaction  of  these  proof  obligations 
allow  us  to  conclude  that  implementation  II  satisfies  specification  E. 

The  proof  obligations  relate  states  of  the  implementation  automaton 
to  sets  of  states  of  the  specification  automaton  and  ensure  that  this  cor¬ 
respondence  is  maintained  during  each  transition  of  the  implementation 
automaton.  To  simplify  the  exposition,  we  refer  to  states  of  the  specifi¬ 
cation  automaton  as  specification  states  and  states  of  the  implementation 
automaton  as  implementation  states.  Define  a  configuration  to  be  any  fi¬ 
nite  set  of  specification  states.  Configurations  are  used  to  describe  sets  of 
reachable  states  of  the  specification  (safety)  automaton.  Transitions  on  an 
event  e  between  configurations  'C  and  C",  denoted  'C  -4  C",  occur  if  and 
only  if 

(i)  C'*0 

(ii)  Vs'  €  C' :  Is  €  'C  :  '»  A  s' 

Thus,  X!  4C'  means  that  (i)  transition  to  some  new  state  is  possible  and 
'ii)  each  new  state  is  a  successor  state  of  some  old  state. 

The  correspondence  between  implementation  states  and  configurations 
is  described  by  a  predicate  J  called  an  invariant  that  associates  a  set  of 
configurations  with  each  implementation  state.  We  write  I(p,  C)  to  denote 
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that  configuration  C  satisfies  invariant  I  on  implementation  state  p.  Two 
proof  obligations  suffice  to  demonstrate  that  the  correspondence  asserted 
by  the  invariant  is  maintained. 

Ol:  p  €  Qn  =*  ( 3C:I(p,C )  A  0  $  C  C  <?°  ) 

02:  >4p'A  J(p,'C)  =►  (3C':'C4C'  A  J(p',C')) 

Obligation  01  ensures  that  for  every  possible  initial  implementation  state, 
there  must  be  a  corresponding  non-empty  set  of  initial  specification  states. 
02  ensures  that  if  the  implementation  automaton  can  make  a  transition 
from  'p  to  p’  on  e  and  'C  is  a  possible  configuration  corresponding  to  'p, 
there  must  be  some  configuration  C’  such  that  'C  A  C’  and  C'  corresponds 
to  implementation  state  p\ 

Demonstrating  the  correspondence  between  implementation  states  and 
configurations  using  01  and  02  is  necessary  and  sufficient  to  establish  that 
L(An)  Q  L(Az)  holds.  That  is,  if  an  invariant  can  be  found  satisfying  Ol 
and  02,  then  L(An)  Q  L(Az)  holds.  And,  whenever  L(An)  C  L(Az)  holds, 
there  is  an  invariant  satisfying  01  and  02. 

Proposition  3  Let  An  be  an  implementation  automaton  and  Az  be  a  safety 
automaton. 

(Soundness)  If  there  is  in  invariant  I  satisfying  01  and  02,  then  L(An)  C 
X(Az)  . 

( Completeness )  If  T(An)  C  i(Az),  then  there  is  an  invariant  I  satisfying 
01  and  02. 

Proof  (Soundness)  Let  w  =  eo,  ei,  •  •  •  be  accepted  by  An-  Thus,  there 
is  a  run  po  Q  p\  ^  •  of  An  over  w.  Since  po  belongs  to  by  condi¬ 

tion  01  there  is  a  configuration  Co  such  that  J(po,  Co)  and  Co  C  Q%.  By 
condition  02,  there  is  a  configuration  C\  ^  0  such  that  X(pi,Ci)  and  for 
all  si  €  Ci  there  is  an  sq  €  Co  and  so  ^  $i-  By  repeating  this  argument, 
we  obtain  Co  ^  Ci  ^  •  •  *.  Thus,  for  any  n  and  any  s  €  C„  there  exist 
so  €  C«, . . . ,  3„_i  6  C„_i,  such  that  So  ^  •  •  •  s„-i  *-**  s.  We  now  construct 
a  forest  of  trees  generated  as  follows.  The  nodes  of  the  trees  are  of  the  form 
Sq  —V  •  •  •  ^  such  that  for  all  0  <  i  <  n,  Sj  6  C<  holds.  The  edges  are  of 
the  form 

(Sq  Q  ^  Snj  Sq  ^  Sn+i), 
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and  the  roots  of  the  trees  are  all  s0  such  that  s0  6  C0. 

This  forest  defines  a  run  of  As  over  w ,  as  follows.  By  definition  of  a 
safety  automaton  is  finite  and  — *s  is  finitely  branching.  Therefore,  the 
forest  consists  of  a  finite  collection  of  finitely  branching  trees.  Hence,  by 
Konig’s  lemma,  there  is  an  infinite  path  through  one  of  the  trees.  This  path 
defines  the  desired  run  of  As  over  w.  Hence,  w  is  accepted  by  As- 

(Completeness)  Assume  I(An)  Q  Z-(As).  Define  J  so  that  T(p,  C)  is 
true  if  and  only  if  C  ^  0  and  p  is  reachable  by  u  for  some  finite  word 
u  =  eo,  •  •  ■ ,  e„_i  (possible  the  empty  word)  such  that 

C  =  {s|3e0, . .  • ,  en-i  and  a  run  so  ^  •  •  •  *^1  s„  of  As  with  s„  =  s} 

Since  Qft  *s  fi^te  and  As  is  finitely  branching,  all  C” s  such  that  I(p,  C) 
holds  are  finite. 

To  prove  that  01  is  satisfied  by  this  J,  assume  that  p  6  Q^.  An  has  no 
dead  states  because  it  is  an  implementation  automaton.  Therefore,  there 
is  an  infinite  word  w  that  is  accepted  by  An. 

Since,  by  assumption  L(An)  Q  £(As),  we  conclude  that  L(As)  is  also 
non-empty,  and  Qg  ^  0  holds.  By  the  definition  of  J,  X(p,  Q £)  is  true,  so 
01  is  satisfied. 

To  prove  that  02  holds,  assume  its  antecedent — that  there  exist  jp,  e,  p 
and  'C  such  that  'p  A  p  and  J( 'p, ' C ) — is  true.  Thus,  there  is  a  finite  word 
u  such  that  p  is  reachable  by  u  and  'C  is  exactly  the  set  of  states  that  As 
might  be  in  after  having  read  u.  Define 

C'={s'\3's  €'C:  iii'} 

Evidently,  p  is  reachable  by  u  -e,  so  C'  is  exactly  the  set  of  states  As  might 
be  in  after  having  read  u  •  e.  Thus,  by  the  definition  of  J,  we  conclude 
l{p',Cr)  holds  and  it  remains  to  prove  'C  A  C\  To  prove  'C  C\  we 
show  that  conditions  (i)  and  (ii)  of  the  definition  of  — ►  for  configurations 
are  satisfied.  Condition  (ii)  is  satisfied  due  to  the  way  C’  was  just  defined. 
To  show  that  condition  (i)  is  satisfied,  note  that  because  p  is  reachable  by 
u  •  e  mad  An  contains  no  dead  states,  there  is  an  infinite  word  w  such  that 
u  •  e  •  w  €  £(An).  By  the  assumption  that  L(An)  Q  L(As),  we  conclude 
that  u  •  e  •  w  €  L(As).10  Therefore,  the  set  C'  can  not  be  empty  and  so  (i) 
is  satisfied.  ° 


10This  is  the  reason  we  have  assumed  implementation  automata  have  no  dead  states. 
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6  A  logic  of  automaton  diagrams 


Proof  obligation  02  can  also  be  formulated  using  triples  similar  to  those  of 
Hoare’s  logic  [9].  We  require  the  following  notation  for  this. 

An  automaton  proof  outline  is  a  program  annotated  with  automaton  as¬ 
sertions.  The  assertions  define  the  invariant  used  in  obligations  01  and 
02.  A  configuration  descriptor  [Pi, . . . ,  Pr;pi, . . .  ,pr]  consists  of  nodes 
Pi, . . . ,  Pr  and  configuration  predicates  pi, . . .  ,p,  (with  r  >  1).  Each  pj,  is  a 
predicate  over  the  values  of  the  program  variables  x  and  the  node  variables 
Xfc  of  node  P/,.  For  a  program  state  (£,  x),  the  configurations  of  the  configu¬ 
ration  descriptor  [Pi,...,Pr;pi,...,pP]  are  all  sets  {(Px,  jCx), . . .  ,(Pr,Xr)} 
such  that  pi  A  ...  A  pr.  Configuration  descriptors  are  used  to  define  sets 
of  possible  nodes  and  value  assignments  that  can  occur  during  an  exe¬ 
cution.  Hence,  the  configuration  {(Pi,J?i), . . .  ,(Pr, ^r)}  means  that  the 
automaton  can  be  in  any  node  P/,  with  value  assignment  Xk-  To  make 
the  notation  clearer,  we  write  (Pi, . . . ,  Pr;  J?i, . . . ,  ftT)  for  the  configuration 

An  automaton  assertion  at  a  program  label  l  is  used  to  define  the  in¬ 
variant  associated  with  program  states  in  which  the  value  of  the  program 
counter  is  l.  Such  an  assertion  is  given  as  a  set  of  m  configuration  descrip¬ 
tors  (m  >  0), 


(i) 


{(Pi.-.pj.irf.-.ri.], 
pr . p.’.;i>r.  •••.K’j) 


This  assertion  defines  J((l,  f),  C),  the  invariant  at  l,  to  hold  if  and  only  if 
pj  A  ...  A  p^.,  where  C  =  (P\,. . .  ,P*.; Xj, . . .  ,X*.)  for  some  i  (1  <  i  <  m). 
Thus,  C  is  a  configuration  of  assertion  (1) — or  C  satisfies  the  assertion — if 
and  only  if  it  is  a  configuration  of  one  of  the  m  configuration  descriptors  in 
the  assertion. 

Obligations  01  and  02  can  be  expressed  in  terms  of  automaton  as¬ 
sertions  of  an  automaton  proof  outline.  To  express  01,  asstime  that  the 

If  An  had  dead  states  then  it  might  be  possible  for  An  to  continue  from  a  dead  state  to 
a  dead  state  (although  not  ad  infinitum )  without  the  specification  automaton  being  able 
to  continue.  In  such  cases,  it  will  not  be  possible  to  associate  a  configuration  with  a  dead 
state,  since  rewriting  requires  configurations  to  be  non-empty. 


15 


assertion  corresponding  the  initial  program  label  has  form  (1).  Then  using 
the  definition  of  the  invariant  given  above,  we  can  rewrite  01  as 

01':  Vx:  3* :  3X[, . . . ,  X'r.  :  pj  A  •  •  •  A  p*r. 

'a  (p:,x|) € qi  a- --a  (p;,, .?;.)€ q? 

where  is  the  set  of  states  determined  by  the  initial  nodes. 

Obligation  02  can  also  be  expressed  in  terms  of  automaton  assertions. 
For  any  two  program  labels  ia  and  1$  such  that  that  1$  can  be  reached 
from  la  by  executing  a  single  atomic  action  (S),  we  can  formulate  02  as 
the  automaton  triple 


(2) 


{[Pi,. 

-.P^rf.-. 

[p?, 

<s> 

{[Q{,. 

•  • ,  Q»i  5  •  • 

•.til. 

IQ?. 

•  •  *  ,  Q«„i  ?",  • 

•  •  »9«J) 

In  an  automaton  triple,  the  assertion  preceding  the  atomic  action  is  called 
the  precondition  and  the  assertion  following  it  is  called  the  postcondition. 
Informally,  the  meaning  of  triple  (2)  is  that  if  'C  is  a  configuration  satisfying 
the  precondition,  then  after  execution  of  (S),  there  is  a  configuration  C’ 
satisfying  the  postcondition  and  'C  — »  C'  holds. 

The  meaning  of  (2)  is  a  conjuntion  of  the  meanings  of  triples  with  some¬ 
what  simpler  preconditions: 

{(Pj, . . . ,  Pr. ;  pj, . . .  ,pjj 

(S) 

[Qi»-  •  •  >  Q*»i  ?"> — ,  ?"*]} 


Thus,  we  first  formalize  the  meaning  of  (3).  This  triple  is  valid  if  and 
only  if  whenever  the  automaton  configuration  and  program  state  together 
satisfy  the  configuration  descriptor  in  the  precondition,  then  executing  (S) 
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produces  a  new  program  state  such  that  there  is  some  new  configuration 
defined  by  one  of  the  configuration  descriptors  of  the  postcondition  and 
there  is  a  transition  from  the  old  configuration  to  this  new  configuration 
on  the  new  program  state.  More  formally,  (3)  is  valid  if  and  only  if  given 
a  program  state  (la,'x)  and  a  new  program  state  (t$,  x)  that  results  from 
executing  (S)  and  value  assignments  X{,. . .  ,'X*.  that  constitute  a  configu¬ 
ration  of  the  configuration  descriptor  in  the  precondition  of  (3),  then  there 
is  some  configuration  descriptor 

(4)  {[Q{ . . ^11 

of  the  postcondition  of  (3)  and  some  value  assignments  X\\ . . .  ,X,'J  such 
that 

is  a  configuration  of  (4),  and 

(pj, .  •  •  ,p:,  ;  * i . *i, ) <!t?  (Qi  -frv . . ,  X;;) 

holds.11 

Thus,  the  meaning  of  (3)  is  given  by 

Trpk  : 

(4,x)  -»n  (tn,x)  a  y\  yv  =» 

(5)  l-v-ri 

31  <j  : 

. a  A  *? 

1  <"><•) 


11  Here,  — ♦  is  the  transition  relation  for  configurations  defined  in  section  5: 

(t±?  (Qi . Q iiiXA.-.X-f) 

holds  if  sad  only  if 

VI  <  *  <  •• 

31  <~h<rf: 
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where  ( la,'x )  — +n  (k>  *  )  denotes  the  transitions  defined  by  (S)  and  where 
the  predicate  p  with  all  its  variables  x  and  X  marked  with  grave  accents  is 
denoted  'p.  Similarly,  p  is  the  predicate  p  with  its  variables  marked  with 
acute  accents. 

The  meaning  of  (2)  is  then 

OS':  A  Trpll- 

l  <«<m 

Triple  Decomposition 

Triples  like  (2)  at  first  may  appear  intimidating.  Fortunately,  such  triples 
can  always  be  decomposed  into  simple  triples  of  the  form: 

{[P;p]} 

b  :  (S) 

{[Q;?]} 

b- 

According  to  (5),  the  meaning  of  such  a  triple  is 

(6)  (4,*)  -»n  (b,x)  A  >  =>  3J?' :  (P;tf)  -  (Q;J?0  A  q. 

Decomposition  of  general  triples  into  simple  triples  is  accomplished  by 
using  the  following  propositions.  The  first  follows  directly  from  the  formal 
definition  of  (2)  as  the  conjunction  of  triples  having  form  (3). 

Proposition  4  To  verify  a  triple  like  (2),  it  is  necessary  and  sufficient  to 
verify  for  each  1  <  t  <  m  that 

{[Pj, . . . , Prj 5 Pi ,  •  •  • 

b  •  (S) 

{[Qi>  •  •  • » Q#i !  9i»  •  •  •  >  9«j]> 

[Q"i  •  •  •  *  Q«„»  ?">•"* 
b  ■ 

holds. 

The  next  proposition  is  a  case  analysis  and  permits  a  triple  like  (3) 
to  be  reformulated  as  a  collection  of  triples,  each  of  which  has  only  one 
configuration  descriptor  for  its  postcondition. 
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Proposition  5  The  triple 


(7) 


{IP.- 

•)P  r  J  Pi »  ■ 

•  •  »Pr]} 

4  :  (S) 

{[Q!»  -  • 

•.Qi.-ffi. 

•.QL;«T 

>•••><£.]} 

iff  • 

if  and  only  i 

f  there 

exist  predicates 

i, . . .  ,'Xr,  where 

1  <  j  <  n  such  that 

(8)  \J  Cj  =  true 

\<j<  n 


and  for  all  1  <  j  <  n 

(9) 


{ [P 1 »  •  •  •  »  P riPlf'lPr]} 

c  .  :  <S>  . 

{[Q{, . <]} 

Iff  : 


Proof  Let  Tpl  be  the  triple  (7)  and  for  1  <  j  <  n,  let  Tplj  be  the  triple 
in  the  corresponding  consequent  of  (9).  It  follows  directly  from  (5)  that 

(10)  Tpl  s  V  Tpl,- 

l<j<n 

(If)  Since,  by  (9),  cy  =>  Tplj  holds  for  1  <  j  <  n,  it  follows  that 
(Vy  Cj)  =>  (Vy  Tpl}).  Therefore,  by  (8),  Vy  Tpl,  holds  and  by  (10),  triple  (7) 
holds. 

(Only  if)  Assume  that  (7)  holds  and  define  for  1  <  j  <  n 


Cj  =  Tplj. 

By  (10)  and  the  definition  of  cy,  Tpl  =  Vy  cy-  Then,  by  the  assumption  that 
(7)  holds,  (8)  is  satisfied.  Condition  (9)  is  trivially  satisfied.  □ 


The  next  proposition  is  used  to  decompose  a  configuration  descriptor 
in  a  postcondition  so  that  nodes  can  be  considered  one  at  a  time. 
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Proposition  6  The  triple 

{[Pi, ,  P  r;  Pl ,  •  • .  ,pr]} 

4  :  (s) 

{[Qn  •  •  •  i  Q*i  9i>  •  •  •  *  9*]} 
4  = 


holds  if  and  only  if  for  all  1  <  k  <  s 


(11) 


{[Pi  j  •  •  •  i  Pf!  Pi »  •  •  •  i  Pr]} 
4  :  (S) 

{[Q  *;9k]} 

4: 


Proof  Follows  directly  from  (5). 


□ 


Finally,  the  configuration  descriptor  in  the  precondition  can  be  decom¬ 
posed  according  to  the  case  analysis  principle  below. 


Proposition  7  The  triple 


(12) 


{[Pi,  •  •  •  ,  PriPl, 
4  :  (S) 

{[Q;  9]} 

4: 


,*]} 


holds  if  and  only  if  there  are  predicates  d*  with  free  variables  x,  x,  'Xh,  for 
1  <  h  <  r  such  that 


(I3)  A  Ph  =>  V 

l<fc<r  l<fc<r 


and  for  all  1  <  h  <  r: 


(14) 


<k 


4 


{[P  h;ph]} 

(s> 

{[Q;  9]} 


Proof  Let  Tpl  be  (12),  and  for  1  <  h  <  r,  define  Tp^  to  be  the  triple  in 
the  corresponding  consequent  of  (14).  It  follows  from  (5)  that 


20 


(is)  «  A  ?»)  a  TPi)  =  <(  a  pi.)  a  v  W,))- 

l<A<r  !<A<r  l<A<r 

(If)  Assume  that  (13)  and  (14)  hold.  According  to  (5),  it  is  sufficient  to  show 
that  (A hPh)  =>  Tpl  By  (13)  we  have  (Aa Ph)  =*  ((A hPh)  A  (Va  <4)),  so  it 
follows  from  (14)  that  {AaPa)  =*>  ((AaPa)  A  (Va  Tplh)).  Thus,  (AaPa)  =► 
(Va  Tplh)  holds,  and  by  (15),  we  obtain  (Aa  Pa)  =>  Tpl,  as  desired. 

(Only  if).  Assume  that  (12)  holds,  i.e.  Tpl  is  valid,  and  define  <ffc  = 
Tpl^  for  1  <  h  <  r.  By  the  assumption,  (Aa Ph)  =►  ((AaPa)  A  Tpl)  trivially 
holds.  Then,  by  (15),  (Aa  Pa)  =»  (AaPa)  a  (Va  Tplh)  holds,  and  by  the 
definition  of  c„  it  follows  that  (AaPa)  =>  (AaPa)  A  (Va^a)  holds.  Thus, 
(AaPa)  =►  (Va ^a)  holds.  Hence,  (13)  holds.  Condition  (14)  is  trivially 
satisfied.  □ 

The  above  decomposition  propositions  are  based  on  having  configura¬ 
tions  defined  by  r  configuration  predicates,  pi, . . .  ,/v — one  for  each  node 
Pr  in  the  descriptor — rather  than  by  a  single  predicate.  Having  these  r 
predicates  permits  the  decomposition  of  Proposition  6,  which  is  something 
that  would  not  have  been  possible  if  only  a  single  predicate  were  used. 

7  Example 

To  illustrate  the  method  of  section  6,  we  consider  a  simple  but  somewhat 
contrived  example. 

Define  the  property  p;  q  to  hold  at  the  present  moment  if  p  holds  now 
and  q  holds  at  the  next  instant.  Such  a  property  is  not  uncommon  when 
reasoning  about  concurrent  systems  and  is  formulated  in  temporal  logic  as 
p  A  o q.  Now,  consider  the  more  complicated  property 

T  :  Property  p;  q  holds  at  least  every  5  instants. 

This  property  is  easy  to  specify  using  a  non-deterministic  automaton,  as 
showrofa  Figure  4.  (Specifying  T  using  a  deterministic  automaton  is  more 
difficuft  because  p;  q  might  hold  in  overlapping  intervals  if  p  and  q  are  not 
mutually  exclusive.  The  automaton  must  keep  track  of  all  guesses  of  such 
intervals.)  A  program,  Ur,  purported  to  satisfy  T  with  p  =  p()  and  q  =  q() 
is  depicted  in  Figure  5.  There,  braces  (  and  )  in  the  if  statement  assert 
that  execution  of  an  atomic  step  from  t\  consists  of  either  executing  p :  "true 
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r  =  *t  + 1  a 

T'  <  5 


and  setting  the  program  counter  to  £2,  or  executing  q -.•true  and  setting  the 
program  counter  to  (q.  We  now  demonstrate  that  Hr  indeed  satisfies  T. 
In  order  to  this,  the  automaton  proof  outline  PO(IIr)  in  Figure  6  is  used. 
(The  notation  is  used  there  to  denote  the  configuration  predicate  true.) 
We  must  show  that  the  proof  outline  satisfies  obligations  01'  and  02f. 

Obligation  Ol'  is  valid  because  the  assertion  at  £0,  {[A;T  =  0]},  is 
satisfied  by  the  initial  state  (A;  0)  of  At,  for  any  initial  program  state. 
The  triple 

{(A,r  =  o)} 

£0  :  (p,q:-  true,  false); 

{[A,  B;T  =  1,_]} 

£\  '• 

is  proved  as  follows.  Using  Proposition  6,  it  is  decomposed  into  the  simple 
triples 

{(A;T  =  0]} 

,  .  to  :  (p*q:*  true,  false); 

{  }  {(A;T  =  1]} 

£\  ■ 

and 
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do 


4>: 

(p , q : ■  true,  false)'. 

h  : 

(if 

true  — ► 

p:*true); 

ii  : 

(qr-true); 

true  — » 

q •.•true) ; 
fi 

od 


Figure  5:  Program  Ht 


do  { tut;:  [A;  T  =  0]} 


t0  : 

(p » q :  ■  true,  false) 

{[A,B;T  =  1,-]} 

h  : 

(if 

true  — ► 

p:-true); 

{[B;  -]} 

ti  : 

(q  •.•true); 

true  — * 

q:»true); 

fi 

od 


Figure  6:  Proof  outline  PO(Et) 
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fl  ■■ 


{[A;T  =  0]} 

{p,q:»  true,  false) ; 

{[B;-]} 


According  to  (6),  the  meaning  of  triple  (16)  is 

((p  =  true  A  q'  =  false)  A  T  =  0)  => 

K  '  (3  T  :(r  =  T  +  lAr<5)  A  T  =  1). 

Here,  (p'  =  true  A  q'  =  false)  is  the  formulation  of  the  program  transition 
— »n  defined  by  the  assignment  statement  at  (Q.  The  predicate  'T  =  0 
is  obtained  from  precondition  {(A;T  =  0]}  by  marking  the  configuration 
predicate  with  grave  accents;  the  automaton  transition  predicate  T'  =  'T  + 
1  A  T'  <  5  is  obtained  from  the  self-loop  of  node  A  in  Figure  4;  and 
the  predicate  T'  =  1  is  obtained  by  marking  the  configuration  predicate  in 
postcondition  {[A;T  =  1]}  with  acute  accents. 

Similarly,  the  meaning  of  triple  (17)  is 

(19)  (( p ’  =  true  A  q' =  false)  A  T  =  0)  =>  ( p '). 

Triples  (16)  and  triple  (17)  are  valid  because  (18)  and  (19)  are  tautologies. 
The  triple  corresponding  to  the  first  branch  of  the  if  statement, 

{[A,B;T  =  1,_]} 

lx  :  (if 

true  — ► 
p:»true); 

«B;4} 

fa  : 

is  verified  by  decomposing  it  using  Proposition  7  and  choosing  true  for  dx 
and  false  for  dj.  Hence,  we  need  to  verify 

{(A;T  =  1]} 

(if 

true  — ► 
p:«tn*e); 

{(»;-]} 


in 

true  => 

fa  : 
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and 


false 


A 


1 2 


(if 

true  — ► 
p:*true); 


The  first  formula  is  equivalent  to 


true  =>  (((/>'  =  true  A  q  =  sq)  A  'T  =  1)  =>  (jp')), 

which  is  a  tautology.  The  second  formula  is  trivially  valid. 

The  triple  corresponding  to  the  second  branch  of  the  if  statement, 

{[A,B;r  =  l,_]} 

<,  :  (if 

true  — > 
q  :mtrue) ; 
to:  {[A;  T  —  0]  J 


is  decomposed  using  Proposition  7  with  false  for  d\  and  true  for  d2,  so  it  is 
necessary  only  to  verify: 


(20) 


A: 


to 


{[B;-]} 

(if 


true  — ♦ 
q:*true) ; 
{[A;T  =  0]} 


which,  according  to  (6),  is 

((P'  =  >A9'=  true))  =►  (3r:(9'AT'  =  0)  A  T  =  0), 
a  tautology.  Finally,  the  triple 

(q:«£rue); 

{[A;T  =  0]} 
to- 

is  the  same  as  (20)  except  for  the  labeling. 
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8  Relation  to  other  work 

Use  of  automata  on  infinite  words  for  program  specification  has  been  stud¬ 
ied  in  different  contexts.  In  [19],  Wolper  used  finite-state  automata  to  de¬ 
fine  temporal  logic  operators.  Alpem  and  Schneider  [3]  demonstrated  how 
invariants  could  be  used  to  verify  that  an  implementation  satisfies  a  spec¬ 
ification  expressed  by  a  finite-state  deterministic  Buchi-automaton.  This 
work  was  generalized  in  [5]  to  Boolean  combinations  of  finite-state  deter¬ 
ministic  Biichi-automata,  and  in  [14]  to  V-automata,  finite-state  automata 
that  accept  a  word  only  if  all  runs  over  the  word  are  accepting. 

Vardi  gave  a  recursion  theoretic  view  of  the  verification  problem  for 
non-deterministic  automata  and  defined  verification  conditions  in  terms  of 
computation  trees  and  product  automata  [18].  Sistla  proved  that  the  verifi¬ 
cation  problem  for  unbounded  non-deterministic  automata  is  n^-complete 
[15). 

For  languages  over  finite  alphabets,  relationships  between  automata  and 
topology  are  studied  in  [6].  Results  similar  to  those  of  section  3  but  formu¬ 
lated  for  stuttering  automata,  were  developed  independently  in  [1], 

In  [17],  Stark  presented  proof  obligations  based  on  automata  for  tempo¬ 
ral  logic  formulas  that  have  two  types  of  variables:  program  variables  and 
logical  variables.  Stated  in  our  terminology,  Stark’s  proof  obligations  rely 
on  an  invariant  relation  that  associates  a  set  of  specification  states  (instead 
of  a  set  of  sets  as  done  in  this  paper)  with  each  program  state.  This  method 
is  not  complete,  because  it  requires  all  specification  states  associated  with 
a  program  state  to  have  succesors  on  any  event.  In  fact,  only  some  of  these 
specification  states  might  have  successors,  and  therefore,  Stark’s  method 
cannot  deal  directly  with  all  non-deterministic  specifications.  For  example, 
the  method  cannot  be  used  to  prove  correctness  of  the  program  in  section  7 
unless  the  specification  is  first  reformulated  as  an  equivalent  deterministic 
automaton. 

Lynch  and  Tuttle  used  automata  for  hierarchical  proofs  of  program  cor- 
rectneH  in  [12].  They  employed  mappings  between  implementation  and 
specification  automata  in  a  way  similar  to  that  of  Stark.  The  method, 
therefore,  suffers  from  the  same  incompleteness.  Jonsson’s  mappings  [11] 
are  also  similar  to  those  of  Stark,  and  therefore  also  incomplete. 

The  method  of  Abadi  and  Lamport  [l]  handles  more  general  specifica¬ 
tions  than  ours,  because  auxiliary  liveness  properties  can  be  attached  to 
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automata.  A  simulation  function  /  is  found  that  associates  a  specification 
state  f(p)  with  each  implementation  state  p.  The  method  is  indirect,  as 
it  relies  on  changing  the  implementation  automaton  by  adding  history  and 
prophecy  variables  so  that  the  implementation  automaton  simulates  the 
specification  automaton.  Enlarging  the  implementation  automaton  with 
information  about  the  specification  automaton  ensures  the  existence  of  the 
simulation  function  /. 

Abadi  and  Lamport’s  work  uses  stuttering  automata,  although  this  is 
not  essential  to  their  results.  A  stuttering  automaton  is  one  in  which  rep¬ 
etition  of  (what  we  call)  events  is  considered  a  single  event.  Since  non¬ 
stuttering  automata  can  both  restrain  stuttering  and  allow  time-bounded 
and  unbounded  stuttering  when  needed,  we  prefer  these  automata. 

Using  a  similar  approach  as  in  [l],  Sistla  developed  proof  obligations 
for  the  same  automata  that  we  consider  [16].  He  observed  that  by  adding 
only  a  history  component  to  the  implementation  automaton,  sound  and 
complete  proof  obligations  can  be  obtained.  These  obligations  use  invari¬ 
ant  relations  that  define  multi-valued  functions  from  implementation  states 
to  specification  states.  Adding  history  information  to  the  implemention 
automaton  makes  each  implementation  state  reachable  by  only  one  event 
sequence;  hence,  only  one  configuration  needs  to  be  associated  with  each 
implementation  state.  In  our  method,  we  circumvent  the  apparent  need 
for  a  history  component  by  associating  multiple  configurations  with  each 
implementation  state. 


9  Conclusion 

This  paper  describes  a  method  for  verifying  that  an  implementation  satis¬ 
fies  any  property  specified  by  a  safety  automaton.  Even  though  all  safety 
properties  can  be  specified  by  deterministic  safety  automata,  we  believe 
that  there  are  advantages  to  using  non- determinism  in  specifying  safety 
properties.  In  particular,  the  use  of  non-determinism  permits  the  writer 
of  a  specification  to  make  different  sets  of  assumptions  about  the  future. 
This  results  in  simpler  specifications,  because  the  disjunctive  nature  of  non- 
determinism  makes  separation  between  several  possible  courses  of  events 
possible — even  before  it  is  clear  which  one  is  the  actual  course. 

The  paper  also  describes  the  first  direct  method  of  verification  for  non- 
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deterministic  automaton  specifications.  Further,  we  have  showed  how  the 
method  can  be  formulated  in  terms  of  proof  outline  assertions.  Thus,  veri¬ 
fication  is  similar  to  that  of  conventional  Hoare-style  logics. 
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